Real Time Transfer Protocol (“RTP”) is the standard protocol defining the real-time transmission of media streams (e.g., voice) over data networks, such as in Voice Over IP. A companion protocol to RTP is the Real Time Control Protocol or RTCP. Referring to FIG. 1, media packets transmitted between A 100 and B 104 and vice versa during a session are formatted and transmitted (continuously) over network 108 according to RTP while additional performance information governing the communication link (e.g., key statistics about the media packets being sent and received by each endpoint (A or B) such as jitter, packet loss, round-trip time, etc.) are transmitted (discontinuously) over the network 108 according to RTCP. Endpoints A and B are typically computational components but can be or include any other form of audio or video communications interface. RTCP performance information is useful not only for the session participants, A and B, but also for a network monitor 112. Network administrators can use such information not only for network administration but also for network troubleshooting and management.
RTCP is specifically designed to provide such information to the network monitor 112 via an IP multicast architecture. In IP multicast, a single packet is transmitted to a group of recipients by first being sent to a multicast address and then being distributed by the network to multiple addresses associated with the multicast address. The group of recipients includes not only the other (receiving) party in the session, namely A or B as appropriate, but also the monitor. When IP multicast is used for RTCP information, it also should be used for RTP information. Timing calculations for RTP packets are made based on the behavior of RTCP packets, and such timing calculations are only an accurate predictor of RTP packet transmission characteristics if both RTP and RTCP packets are transmitted by IP multicast techniques. IP multicast is generally disfavored because multicast is complicated which causes administration complications and difficulties.
A common architecture for transmitting media streams between two session participants is known as unicast. In unicast, the packets are transmitted to only one and not multiple destinations. It is more difficult for the monitor to collect and analyze RTCP packets as the packets are transmitted only to the other session participant and not to the monitor.
To enable the monitor to obtain RTCP packets, a dual unicast architecture has been developed. In dual unicast, one session participant (A) transmits both RTP and RTCP packets to the other session participant (B) and RTCP packets to the monitor. Dual unicast, however, exposes design limitations in the RTCP protocol itself. Although endpoint session ids are unique to a particular (first) session (such as between A and B), an endpoint in a concurrent (second) session (such as between C and D) can have the same session id or synchronization source id (“SSRC”) as an endpoint (A or B) in the other (first) session. When duplicate endpoint session ids are concurrently in use, the monitor can have substantial difficulty determining which RTCP packets correspond to which session, potentially causing inaccurate performance analysis.
By way of illustration, in the example above assume that A sends an RTCP packet addressed to B and an RTCP packet addressed to the monitor. The RTCP packet addressed to the monitor includes A's transport address, A's SSRC, and B's SSRC but does not include the transport address of B. Likewise, C sends an RTCP packet addressed to D and an RTCP packet addressed to the monitor. The RTCP packet addressed to the monitor includes C's transport address, C's SSRC, and D's SSRC but does not include the transport address of D. If B and D have the same SSRC, the monitor is unable to definitively determine that a selected RTCP packet sent to either B or D corresponds to the A-B session or the C-D session.